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I. INTRODUCTION 



In the United States Navy there are several watch stations that require a 
substantial investment in both time and energy to not only develop the skills and 
knowledge base, but also to earn the confidence and trust of the Commanding 
Officer (CO). One of the most critical positions is that of Tactical Action 
Officer (TAO). The TAO has the authority to engage the enemy and release 
weapons in the absence of the CO. The Navy organization manual [Ref.l] states 
the following duties of the TAO: 

a. Basic Function. When assigned, the Tactical Action Officer 
is the commanding officer’s representative concerning the tactical 
employment and the defense of the unit. 

b. Duties, Responsibilities, and Authority. The TAO is 
responsible for the safe and effective operation of the combat 
systems and for any other duties prescribed by the commanding 
officer. Circumstances permitting, the TAO shall carry out 
promptly and precisely special orders and shall report deviations to 
the commanding officer. 

Currently, much of the data required by a TAO is contained in publications 
that must be manually assimilated. This can take an inordinate amount of time to 
find critical information. Manual data retrieval methods typically increase the 
probability of selecting incorrect data which, in turn, results in an erroneous 
evaluation. Other information required by a TAO is contained on turnover 
sheets and written on status boards. Many times this information is not kept 
current or may be forgotten altogether. This can result in critical and/or 
perishable information being lost during the normal watch to watch turnover. 
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These problems can be solved with development of an application that would 
greatly assist TAO’s in their duties by automating the myriad functions that a 
TAO must accomplish in his or her normal watch duties. These would include 
the searching of data to match an emitter with a platform or having available the 
current status of all ships’ weapons and engineering systems. This application, 
Threat Evaluator, would be developed in accordance with the Argos architecture 
[Ref. 2]. This architecture specifies a multi-media interface that provides access 
to a real time database. This application interface would support text, graphics 
and audio to achieve the most desirable interface possible. 

The environment in which Threat Evaluator was developed is HyperCard™, 
whose scripting language is Hypertalk™. Information on this environment can 
be found in Apple’s HyperCard User’s Guide [Ref 3]. This environment proved 
to be quite efficient in the production of the prototype application. The Threat 
Evaluator and HyperCard operate on Apple Macintosh™ 1 computers. An 
important point is that Threat Evaluator can be converted for use on any 
Microsoft disk operating system (MSDOS) platforms which would facilitate its 
implementation throughout the fleet. 

The purpose of this thesis is to demonstrate the feasibility of a tactical 
evaluation tool that will aide in the identification of platforms that may pose a 
possible threat to U.S. forces. The tool will also give the TAO relevant own 
ship’s information so that tactical decisions can be made knowing all required 
information. 



*Hypercard™ and Hypertalk™ are trademarks of Apple Computer 
Incorporated. 



2 



II. PROBLEM STATEMENT 



One of the most important qualifications and subsequent duties of a Surface 
Warfare Officer is that of TAO. It is the pinnacle qualification that a junior 
officer can achieve resulting from training, acquired knowledge and trust . It is 
also quite an identifiable achievement a CO can bestow; proclaiming that a junior 
officer is capable of fighting the ship in battle. The CO that conducts the 
qualifying process puts great trust in each of the officers that he or she qualifies. 
Stringent qualification requirements and thorough knowledge of own ship and 
other potentially hostile ship’s characteristics and capabilities are essential to 
proficiency and success as a TAO. 

Although the TAO position is quite important and essential, after the 
qualification process has been completed there is little continuous training 
conducted to maintain this high degree of readiness. Continued training is 
usually left to each TAO with little or no guidance. Normal means of keeping 
proficient is rote memorization. This process may be helpful in the short term, 
but must be continually refreshed in order to keep the knowledge base readily 
available and current in memory. It is difficult for the TAO to keep current all 
hostile, or potentially hostile, ships memorized and easily accessible at a moments 
notice. The will to train is often hampered by the sheer mass of data that must 
be memorized. The unappealing volumes that contain the data must also be 
learned to use. Methods that will give the data more appeal and even an exciting 
means of learning required knowledge would pique interest while being 
functional and informative. 

Another problem encountered in the normal watch duties of the TAO is the 
time consuming evaluation of each emitter signal detected. The usual flow of 
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information starts with the detection of an emitter by the Electronic Warfare 
(EW) suite aboard After the initial detection, search algorithms on the detection 
equipment attempt to make a match with the signal detected. This search usually 
takes longer than desired and may result in an incorrect evaluation. The search 
algorithm itself may not be optimal resulting in a slow search and retrieval 
process. The search is also conducted manually by EW personnel using printed 
reference volumes. This is done in order to reduce the number of erroneous 
matches that result from software searches alone. The whole process is time 
consuming and prone to errors. 

Current tools available to U.S. Navy Combat Information Center (CIC) 
watchstanders, all of whom work for the TAO, for threat evaluation and 
recognition training are limited. Naval Warfare Publications (NWP), are used to 
search for data that is of primary concern. Of note, there is no quick reference 
available for correlation of essential initial identification information while in a 
tactical environment. By its very nature, this limits the flow of critical 
information that the TAO must have to support the decision making process. 
Loss of time conducting manual searches for information contained in hard copy 
volumes adversely affects the defensive posture of a single ship as well as the 
overall combat readiness on an entire battlegroup. 

The effective transfer of information during watch turnover is crucial to 
watch continuity. Word of mouth, status boards, notes scribbled on paper and 
even seemingly organized notebooks have been the historical means of 
transferring current tactical as well as material status. Although this may prove 
effective in an isolated number of cases, for the most part essential information is 
left out or altered slightly by the typical watch to watch turnover. If notebooks 
are used for turnover information, the notebooks or status boards may not be 
updated in a timely matter, or may even be totally neglected. Additional clutter 
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is the result of paper turnovers and it leaves the oncoming watchstander sorting 
the remaining pile for useful bits of information. Visual means of exchanging 
data on electronic media is the most efficient choice available. Off the shelf 
technology can provide significantly more efficient data retrieval and a graphical 
interface that will aid this entire process. 

A review of current procedures and first hand experience have revealed a 
number of items that should be improved for greater efficiency. These are: 

• Resources are currently manual in nature, often leading to slow, inefficient 

information retrieval. Unwieldy publications and microfiche are the 
primary mechanisms for data storage and the only vehicle for training 
watchstanders. 

• After qualification, TAO’s typically have no formal training in threat 

evaluation as a means of maintaining/improving proficiency. 

• Reference and training tools are not centralized, often requiring users to visit 

various locations to collate/coordinate the tools and information and to have 
access to the proper equipment. 

• The lack of user friendly aids to threat evaluation is often frustrating to 

many TAO’s. 

Automation of many of the manual functions, such as searching databases and 
recording critical watch information to relieving watchstanders, would greatly 
improve the efficiency of the evaluation process. There are, however, factors 
that would be of primary concern in determining the implementation of such an 
application. These factors are reliability of the hardware system and the ease of 
use of the application. 

The reliability of the system includes many items. Preferably, it should be 
more reliable than systems currently in use. Methods of protecting data and 
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applications from viruses as well as disk, system and application crashes should 
be carefully considered. A variety of media exists for data backup. Floppy 
disks, tapes, optical disks, hard disks and removable hard disks are all readily 
available and accessible. 

Data updates are of primary concern to the user. The importance of having 
accurate, time sensitive information is critical. Efficient and easy methods of 
updating existing information would be important in saving time and effort as 
well as money. Determining the best possible method of delivering updated 
information is also a crucial problem. 

The emphasis on ease of use cannot be over stressed. The goal is to make the 
application intuitive, thereby allowing novice users easy access to its capabilities. 
If the application requires enormous manuals and cryptic documentation be read 
and filtered prior to use, then ultimately th.e product will not be used. 
Determining which environment will best suit this requirement is an important 
undertaking. 
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III. SOLUTION 



The recommended solution and the focus of this thesis research is the 
automation of numerous manual tasks that are conducted by the TAO and other 
watchstanders. Automation of procedures would simplify and streamline the 
warfighting capability of any warship. The speed at which many of the 
procedures can be accomplished through automation will significantly increase 
productivity of a TAO and his/her watch team. This solution is composed of 
both hardware and software. Both are crucial to ensure successful operation and 
integration of a total system into the fleet. 

A. HARDWARE SOLUTION 

Hardware is vitally important in an enclosed shipboard environment because 
space is scarce. The smaller a system is, the better it will support limited space 
of fleet units. A micro computer is an excellent choice. The cost of micro 
computers has dropped dramatically in recent years and they have become quite 
affordable. Micro computers with speeds in the 16MHZ-25MHZ can be 
purchased for under $3000. Most micro computers contain a number of 
additional features such as sound, expansion slots and network capabilities which 
ensure a system could be expanded to meet future requirements. 

The ability of the micro computer to support sound is an important factor. 
For example, sound can be a critical feature in the evaluation of EW parameters. 
Sound capability could assist the users in identifying various platforms by 
matching emitter parameters contained on those platforms. Other 
implementations of sound, such as acoustic signatures, could be used to further 
enhance the solution. Speakers and associated sound supporting equipment 
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should come included in the micro computer rather than having to buy an 
additional equipment in order to add this feature. This will provide two benefits: 
first, is the elimination of requirements to have the expertise and tools available 
to install sound equipment; second, the cost of buying required sound equipment 
would be avoided. The micro computer that includes sound capabilities may be 
slightly more expensive in the initial purchase, but when the cost of the 
installation tools, the installation of the sound equipment, and the sound 
equipment itself are added to the price of the micro computer that did not have it 
previously installed, the result is an overall lower cost for the one having the 
capability built into the micro computer. 

The ability of a micro computer to be expandable is also crucial in the 
selection of a micro computer. Many micro computers have expansion 
capabilities available through expansion slots. Expansion slots provide the means 
of installing additional cards that add useful features. These capabilities include 
24 bit color, file compression and networking. It is important that future 
requirements be considered when selecting a micro computer for 
implementation. 

The ability of a micro computer to support networking is fast becoming an 
essential part of any computer solution. The ability to share data and resources 
between multiple user computers, as well as different types of computers, is a 
significant attribute. A multi-user environment is necessary for complete 
implementation of a solution. Users typically use only a portion of data from the 
solution application. Examples of multiple users that would use a solution 
application may be the CO, Executive Officer, Department Heads, TAO’s, and 
on-watch personnel such as those in the CIC, EW and ASW modules. A 
networking capability must be available in the micro computer selected. 
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An important part of a hardware solution, in addition to the micro computer, 
is a monitor. A monitor is essential for displaying data that is generated from 
the micro computer and solution application. Over the last few years, monitors 
have become quite inexpensive. High resolution color monitors can be purchased 
for approximately $500. The resolution of the monitor is important because the 
graphics that will be displayed in the application must be clear. A thirteen inch 
monitor having a 640 by 480 pixel display with 72 dots per inch (dpi) resolution 
should be sufficiently high in resolution to show the required graphics. 

B. SOFTWARE SOLUTION 

When considering a specific software environment to be used in the 
generation of a solution application, there are a number of criteria that should be 
evaluated in order to choose the most desirable option. These criteria can best be 
described as features that the environment will support. These features for a 
development environment include reusable code, modularity and rapid 
prototyping capabilities. Features of the solution application include: a 
multimedia interface, rapid search, display of windows, graphics, sound, tailored 
menu capabilities and machine independence. 

1. Development Environment 

The software development environment chosen should support two 
main features. The first is modular design and the second is reusable code. This 
is by no means an exhaustive list of requirements, but these two are certainly 
essential to the solution of this specific problem. 

The development environment must support a modular program design. 
This design will make the expansion of the solution application much easier to 
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implement. Whitten, Bentley, and Barlow [Ref 4] say the following about 
dividing a program into modules: 

Given these programs, we want to break them into manageable 
modules around which program specifications will be written. 
Programmers can then build and test each module independently. 

Then modules can be integrated according to the structure chart 
and tested as a whole program. 

This approach to program design would enhance the solution application since 
the program data would lend itself to a modular design. For example, some of 
the required data would be divided into countries. Each of the country modules 
would contain the information on the equipment and platforms owned by that 
country. 

Reusable code has become a buzzword in the software development 
community. Reusable code promotes efficiency in the development of new 
applications or new modules that will be add-ons to existing applications. 
Reusable code still requires some modification, however the savings that such 
code generates makes the cost of such changes insignificant when taken in 
aggregate. Powers, Cheney, and Crow [Ref 5] state the following: 

Systems designers have long been interested in the concept of 
reusable code. The idea is to write general purpose modules that 
can be used in many programs, thereby reducing the overall 
programming and testing effort during development and 
simplifying the on-going maintenance effort. The large majority of 
program code involves routine processes such as data entry and 
verification, file maintenance, and report writing. It should be 
possible to create a standard set of modules supporting these 
operations that could constitute 70 to 80 percent or more of the 
code for a new system. 
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These two factors, modularity and reusable code, contribute to a rapid 
prototyping environment that would support quick delivery of a product to the 
fleet. Prototyping is an excellent way to determine additional requirements and 
solutions before the final product is distributed to end users. 

2. Application Solution 

This solution application includes a multimedia interface for real time 
databases that supports text, graphics and audio. This capability would be 
required to provide the needed data that a TAO would use in the course of 
his/her duties. These capabilities are also essential in displaying that data in a 
timely, easy to assimilate manner. 

This application must have a rapid search capability. From a users’ 
perspective this feature is quite important. In a tactical environment, a rapid 
search could mean the difference between the success or failure of a mission. 
Vast amounts of data must be searched increasing the need for a search to be fast 
and accurate. 

The manner in which information is displayed is very important. The 
user should be able to easily distinguish different parts or categories of 
information from one another. An ideal way to do this is to display the 
information in windows that appear as specific queries are selected by the user. 
This provides a quick means of assimilating data. The solution application 
should support this method of data display. From a human factors point of view, 
this is a better interface. 

Graphics are an essential part of this solution application. They are 
used to enhance recognition of platforms for training and tactical situations and 
also to make the interface user friendly. The power of a user friendly interface 
cannot be underestimated. The easier it is to understand and use the application, 
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the greater value it will provide end users as a tool for accomplishing their 
missions. Graphical user interfaces provide clear, concise object relationships 
that a user with only modest experience can easily associate. Pictures of familiar 
objects on the screen guide a user to operate the application. A user sees an icon 
in the shape of a missile, he or she should expect information about missiles to 
come from using that icon. The interface is intuitive which adds to the 
desirability of the application. Considerable thought and study must be 
incorporated in the design of an interface. Graphical capability is a means to 
achieving this desired result. 

Sound is another method of providing information to the user. For 
example, sound could be used to distinguish one level of a program from another 
or to provide an audible alarm that will alert the user if needed. There are many 
other options that could also employ sound to assist the user. 

In order for an application to be adapted to a specific use, menus of the 
program should be tailored to support needed functions and information. 
Tailored menus allow the user to quickly identify his or her options for 
retrieving desired data. Menus support the proper setup and flow of information 
to the user. 

It is crucial that the application be machine independent and 
transportable to other hardware. This would then allow the application to be 
available on most hardware in use in the fleet. True machine independence 
provides an application with an enormous platform base upon which to operate. 
Access by all fleet users increases the ability to develop and capitalize on large 
user groups. 
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IV. IMPLEMENTATION 



A. OVERVIEW 

The Threat Evaluator was developed in a HyperCard environment on a 
Macintosh II computer. HyperCard comes free as system software with all 
Macintosh computers. The assumption in this chapter is that readers are familiar 
with HyperCard. In Threat Evaluator, all algorithms and modules have been 
thoroughly considered throughout the development process. Threat Evaluator 
can be implemented as an additional module to the Argos System or as a stand 
alone application. For the purpose of the prototype, the Threat Evaluator is 
made up of Five modules and is modelled after a FFG-7 class ship There is the 
Threat Evaluator module, the U.S. Aircraft data file, the U.S. Surface Ship data 
file, the U.S. Submarine data file and the Threat Evaluator Help data file. The 
modular design was considered the best option for future expansion of this 
application because every country that has military equipment would be modelled 
in a data file. For example, Germany would have its own data file containing 
information on its’ platforms. This modular approach also conforms to the 
design of the Argos system. The Threat Evaluator is the most tailored tool to 
date that gives a TAO continuous personal training as well as evaluation of 
platforms that may pose a possible threat to the safety of the ship. 

HyperCard has met all the criteria for the software environment solution. It 
supports both modularity and reuseable code. Reuseable code features of 
HyperCard support a high percentage of the code needed for development of all 
the modules. 



13 



B. STARTUP SCREEN AND MAIN MENU CARDS 



The startup screen displays high resolution graphics and plays digitized 
soundt to show the many capabilities of HyperCard and a Macintosh as soon as 
possible. A picture of a U.S Aegis cruiser was placed over a background that has 
a marble like appearance. This was done to give the user the feeling of viewing 
a warship in a background of space giving a futuristic appearance. The sound 
was used to welcome the user to the Threat Evaluator as well as demonstrate 
digitized sound. The command to play the sound is contained in the card script. 
Digitized sounds for the stacks were installed using the MacRecorder® by 
Farallon™ 2 . These sounds were then placed into the main Threat Evaluator stack 
as resources. These resources could then be called and played as required. 

The startup screen dissolves into the main menu screen. This visual effect 
was included to demonstrate one of the many screen change features of 
HyperCard. The dividing line in the center of the main menu screen is used to 
distinguish training areas from actual tactical applications. The training portion 
of the screen, above the separation line, has three card layer buttons. The three 
areas modeled were aircraft, surface ships, and submarines. Each of these card 
buttons has an associated icon that correlates the name displayed to the button. 
For example, the aircraft button has an icon in the shape of a jet. This was done 
to give an additional visual confirmation to the user of what is being selected 
when he or she clicks on that button. Each of the buttons calls an external 
command (XCMD) that generates a popup menu. The countries contained in the 
popup menus for each of the aircraft, surface ships and submarines buttons are 



2 MacRecorder® is copyrighted by Farallon Computing Incorporated. 
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categorized in accordance with the International Institute for Strategic Studies’ 
(IISS) yearly publication [Ref. 6]. This publication provides a well organized 
categorization of various countries. The country and department modeled on the 
aircraft and surface ships card buttons is the United States and the U.S. Navy 
(USN). The United States is modeled on the submarines card button. The scripts 
for the aircraft, surface ships, and submarine menus are contained in Appendix 
A. The categories provided by the IISS were determined to be a reasonable 
manner in which to categorize the data within the Threat Evaluator. 

Selection of items on the popup menus contained in the aircraft, surface ships 
and submarine card buttons take the user to a second level menu screen. The 
specific country or department chosen from that first menu is broken down into 
the various agencies on the second menu screen. These agencies have control of 
the equipment (aircraft, surface ships, submarines) selected from the first menu 
screen. For example, after selection of “USN” under the aircraft card button on 
the first menu screen, the screen changes to display the types of squadrons 
associated naval aircraft. The user then has access to the individual aircraft type 
within each squadron designation. These squadron designations are in 
accordance with Ball [Ref 7]. Representative scripts for the second menu screen 
card buttons are contained in Appendix A. The second menu screen has a 
horizontal dividing line to differentiate fixed wing aircraft from helicopters. 
This provides another visual confirmation to the user. Squadrons and ship 
classes are not all inclusive but were chosen to represent different communities. 

C. INFORMATION CARDS 

After a specific aircraft, surface ship or submarine is chosen from the second 
main menu screen the user is then shown the card with that specific platform. 
On the card there are features that will be of assistance to the user in 
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categorizing the possible threat to his own ship. Capabilities of the platforms are 
divided into the four warfare areas modeled. The warfare areas chosen were 
anti-air warfare (AAW), anti-surface warfare (ASUW), anti-submarine warfare 
(ASW), and electronic warfare (EW). Not all warfare areas were modeled due 
to time constraints. Labels for the card button associated with the warfare areas 
were placed into the background because these labels would be used on all 
platforms within the stack. The actual buttons were placed in the card layer 
because the popup menu would have to be tailored for each platform. These 
card buttons can be copied and used in new cards and easily modified for other 
platforms since the script is copied along with the card button. Repetition of 
equipment that appears under these warfare menus is purposely done to show the 
possibilities of using a certain system in more than one mode or warfare area. 
For example, a surface to air missile may also be used in a surface to surface 
mode. This repetition would assist the TAO in remembering the capabilities of 
various weapons. Scripts for the warfare area buttons are contained in Appendix 
A. Equipment and systems listed in the menus for the F/A-18 Hornet [Ref 8], the 
Oliver Hazard Perry class frigate [Ref 9], and the Los Angeles class submarine 
[Ref 10] were taken from Jane’s Fighting Ships and Jane’s All The World’s 
Aircraft. 

After a weapon or electronic system is selected from the menu of a warfare 
area, a window appears containing specific data and characteristics that a TAO 
may require for proper tactical evaluation. The windows are actually card fields 
being displayed upon the selection of a menu item. The use of card fields was 
determined to be ideal in separating system data in a logical systematic manner 
and providing a visual consolidation of information for the user. Card fields 
containing data have been locked to prevent inadvertent alteration of the data. 
This gives an added measure of security as well as ensuring that data remains 
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intact. There are many card fields containing information on each card. Each is 
given a specific name and that name is placed in the script of the applicable 
warfare area button. Once the field is displayed, it can be hidden again by 
clicking the cursor within the field. This format of displaying data will be useful 
in training prospective TAO’s. The method of data display is also useful for 
training prospective TAO’s since on-line quizzing can be accomplished within 
each warfare area. 

D. SEARCH AND IDENTIFY FUNCTION 

One of the most crucial and useful functions available to the TAO in the 
Threat Evaluator application is the Search and Identify option. This option is 
located on the main menu screen for easy access by the user and is vital for quick 
identification of an incoming threat associated with a particular emitter or 
weapon system. The search and identify screen contains three card fields, one of 
which is hidden. The name of the hidden card field is “stacks to search”. Scripts 
[Ref 1 1] for the visible fields are found in Appendix A. The first field receives 
the search string that will be compared to all the data card fields of the 
information stacks. The search algorithm will search each stack that is listed in 
the hidden field. Additional stacks that are created would merely need to be 
added to this field. Upon a match of the search string and the name of a data 
field, the name of the card and the name of the stack in which a match was found 
is returned and displayed in the second visible field. 

The second field displays the name of the platform and the name of the stack 
on which the platform is located. These are separated by a comma and the 
number of matches displayed is unlimited. If a TAO desires further information 
on a particular platform, he or she merely uses the mouse to click on the desired 
platform’s name and the information card for that platform is displayed instantly 



17 



by pushing the search card. This is done so that the user can return to the search 
card and evaluate further matches. The card field displaying the results of the 
search is locked to permit the routine to work. This routine was considered an 
essential function of the search card. The TAO had to have the capability to 
quickly evaluate the results of the search without having to navigate back through 
menus. This routine allows the TAO to evaluate in detail the capabilities of each 
of the platforms found by the search. 

E. TAO STATUS BOARD 

The TAO status board was created to give a TAO a place to record 
information that was critical for the proper conduct of the watch. He or she also 
needed a place to record any information that would be pertinent for following 
watch sections. The TAO status board is an ideal tool for easy access to all 
required ships’ information. The TAO status board is comprised of two cards 
that display critical ships information. The combination of these two cards 
assures that the TAO has available all data essential to fighting the ship. Two 
cards were determined appropriate to hold all the information that would be of 
importance while not requiring an excessive amount of searching by the TAO 
through many cards. The first card was chosen to hold general data that would 
be easy to assimilate at a glance. The second card was constructed to hold more 
detailed data regarding the casualties of various engineering and combat systems. 

The first card of the TAO status board displays tactical weapons systems’ 
information. Weapons status and condition of readiness are displayed at the top 
of the screen. The position of this was important because a TAO must first be 
aware of the weapons status ordered. The screen is essentially divided into three 
main segments in order to logically collate data. The segment on the left of the 
screen contains ASW related information including associated weapon’s systems. 
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Information such as the mode of the sonar, water conditions for the day and 
torpedo loading data are essential for ASW operations. Radio buttons (which are 
small round buttons) and text fields were used to accept and display information. 
The torpedo tube graphic serves to give the user a visual reference of which 
tubes are currently loaded. The segment on the right of the screen contains 
information on the installed gun systems. This information would be required in 
any AAW or ASUW engagement. Information is also displayed through the use 
of text fields and buttons. The segment on the lower center of the screen shows 
the remaining missiles and their respective locations in the magazine. This 
display gives the TAO a visual perspective as to the remaining missiles and their 
locations after a firing. Each of the cells contain four buttons, each symbolizing 
the three types of rounds (SM-1, blue bird, harpoon) plus an empty cell symbol 
that would be generated once a missile from that cell was fired. The symbols 
chosen were representative of the actual rounds and an empty cell was given an 
“x” symbol. 

The second screen of the TAO status board is divided into two main sections. 
The left side of the screen is the combat systems status and the right side of the 
screen is the engineering status. This information is very important to the TAO 
because the material condition of either of these two areas directly affects the 
combat readiness and the survivability of a ship in combat. If there is any 
degradation in the equipment, then the TAO must be aware of what is not 
working and what effect its’ failure has on the combat readiness of the ship. 
Card text fields were considered necessary to hold information on what 
equipment has a casualty, what effect the casualty has overall and what, if any, 
scheduled maintenance. 
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F. TACTICAL ALGORITHMS 

This module has not been developed. A stub was placed here indicating 
future possibilities. Ideally, it should be capable of using tactical algorithms that 
would calculate the probability of kill (Pk) against a particular target with a 
selected ship’s weapon. This would then give the TAO the optimum weapon 
release point against that target and the number of weapons to use in any given 
engagement. The TAO would then have a solid recommendation on which to 
base his final decision. 

G. INTER-STACK BACKGROUND BUTTONS 

There are a number of references which a TAO must read and be familiar 
with. These written orders should be easily accessible to the TAO. Throughout 
each of the modules of Threat Evaluator, the TAO has access to a number of 
background buttons. The background buttons of note are Battle Orders, Rules of 
Engagement (ROE), Night Orders, Pass Down Log (PDL), INCSEA signals and 
Allied Tactical Publication (ATP) signals. 

Battle orders, ROE, night orders and PDL cards were constructed in the 
same format. A scrolling field was chosen to hold the data. This field can 
expand as the amount of data grows. The field will hold a total of 30,000 
characters [Ref 12]. A button prints the time and date into the field when 
required by the user. The time/date stamp was considered necessary so that the 
user could identify any new entries since the last time he/she read the file. 

The INCSEA background button displays a card that defines the future use of 
this module. The module would contain all the signals from the INCSEA 
agreement. These signals would be displayed either in a list or a specific signal 
could be encoded/decoded as required. The signal would be input by the TAO, 
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resulting in the encoded/decoded signal displayed on the screen. Construction of 
this module is a follow-on to this thesis. 

The ATP- 1(C) background button displays a card that defines the planned 
future use of this module. This module will contain all the signals from the 
ATP- 1(C) volume I and II. These signals would be displayed either in a list or a 
specific signal could be encoded/decoded as required. The signal would be input 
by the TAO, resulting in the encoded/decoded signal displayed on the screen. 
This module is also a follow-on effort to this thesis. 
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V. LESSONS LEARNED 



There are several lessons learned from the development of the Threat 
Evaluator application tool. Programming and interface standardization is 
especially crucial with future modules that supplement the Threat Evaluator 
application since it is an iterative and continuous development process. This 
standardization would assist the developers in the construction of new modules or 
data files. Important lessons learned include the use of sound and graphics to 
achieve unique methods of data representation. These lessons will provide 
valuable information for future module development. 

The first lesson learned was in the use of graphics. The careful utilization of 
graphics was determined to be a benefit and not a distraction to the user. This 
determination came from demonstrating the application to interested individuals. 
Graphical representation of familiar objects creates a more acceptable 
environment to new users of the application. Objects that appear in the users’ 
normal work routine and duties are taken and represented graphically in the 
application. Implementing this graphic representation into the application results 
in the user bringing previous knowledge to the application. This gives the 
application an intuitive interface. This intuitiveness is highly sought after in an 
application such as Threat Evaluator. 

The second lesson involved unique benefits of using sound as another means 
of transmitting information to the user. Sound provided the user with a variety 
of data. Digitized sound was used to repeat what main menu function he or she 
was choosing. This supplied the user with an audio confirmation of his or her 
actions. Computer generated sound was used after the first main menu screen. 
The differentiation of digitized sound and computer generated sound gives the 
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user the positive reinforcement that he or she is in a different part of the 
application. The demonstration of both types of sound lends credibility of the 
sound capabilities and their further expansion into other areas of this application. 

The third lesson learned was the proper method of program and data design 
in constructing the Threat Evaluator. Initially, Threat Evaluator began as a 
single stack. However, this became cumbersome and changes to the stack were 
often difficult to incorporate. A modular concept of data was determined as the 
most convenient and cost effective method. For future additions to the Threat 
Evaluator, modularization would facilitate the replacement of old data files with 
new ones. This modular concept allows a specific program area or data file to 
be worked and updated as necessary, then easily reintroduced into the main 
application. This method will reduce the code necessary for implementation in 
fleet as opposed to a system that was not of a modular composition. 

The fourth lesson learned was to include proper documentation for the 
application’s operation. Appendix B contains a user’s manual that describes the 
operation of Threat Evaluator. This documentation assists the user in the proper 
operation of the functions and features of Threat Evaluator. 
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VI. CONCLUSIONS 



The development of the Threat Evaluator tool has shown the feasibility of an 
automated reference and evaluation tool. The modular design of the application 
as well as the quick prototyping aspects of the Hypertalk language show that the 
HyperCard environment can be both economical and technically sound for future 
development of projects of this sort. Many provisions greatly needed by TAO’s 
have been incorporated into the Threat Evaluator. These features can be fine 
tuned and tailored as further iterations of the application are developed. 

The storage media most likely to be of greatest benefit for the Threat 
Evaluator is compact disk read only memory optical storage (CD ROM). This 
would be best for a number of reasons. First, the CD ROM disks will hold about 
550 megabytes of data. This large volume is necessary to hold all of the data that 
is required for a fully implemented Threat Evaluator application and data Files. 
Once Threat Evaluator has been completely implemented, every country that has 
military equipment would be represented by a module that contained information 
on that equipment. Today the only true alternative for this amount of data is CD 
ROM. Second, distribution of CD ROMs would be easy. Cognizant agencies 
would merely send new CD ROMs to fleet units as updates to the data files are 
required. Users would then be able to return the old CD ROM for proper 
destruction or sanitization of data. Third, distribution disks would be read only 
memory. Fleet personnel would not be able to alter the information contained 
on the CD ROM. This ensures that all units will have the same data Files. 
Finally, optical disks are quite sturdy and are not easily damaged by normal day 
to day use. This will provide protection of the data as it is in transit to the user 
facility. 
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Future areas of study directly relating to the Threat Evaluator application 
include: 

* Development of a module that incorporates probability of kill algorithms to 

generate a recommendation to the TAO. 

♦ Development of a module that incorporates the signals and data in volumes 

one and two of ATP 1(C). 

• Development of a module that incorporates the INCSEA signals. 

• Determination of which storage media is truly best for this application to 

include CD ROM, tape drives and removable hard disks. 

The development of the Threat Evaluator supports the Argos environment 
and the concept of a paperless ship. It provides the TAO with an exceptional tool 
for analysis of tactical operations. It also provides the user with a method of 
clear and concise information transfer between watch sections. 
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APPENDIX A 



SCRIPTS FOR THREAT EVALUATOR 

A. CODE FOR THE MAIN MENU SCREEN POPUP MENUS. 

1. Aircraft button 
on mouseDown 
play aircraft 

put ’’United States, USN,USAF,USA,USMC,USCG,NOAA” into aircraft 
put return & ’’Soviet Union” after aircraft 

put return & ”NATO,Belgium,Canada,Denmark, France, Germany ,Greece,”-i 
&”Iceland,Italy,Luxembourg,Netherlands,Norway,Portugal,Spain, Turkey,”-. 
&”United Kingdom” after aircraft 

put return & ’’Warsaw Pact,Bulgaria, Czechoslovakia, Hungary, Poland,”-. 
&”Romania” after aircraft 

put return & ”Mideast & North Africa, Algeria,Bahrain,Djibouti,Egypt,”-. 
&”Iran,Iraq,Israel,Jordan,Kuwait,Lebanon,Libya,Mauritania,Morroco,”-. 
&”Oman,Qatar,Saudi Arabia,Somali Republic, Sudan,Syria, Tunisia,”-. 
&”United Arab Emirates,North Yemen, South Yemen” after aircraft 

put return & ’’Sub-Saharan Africa,Angola,Benin,Botswana,Burkina Faso,”-. 
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&”Burundi, Cameroon, Cape Verde, Central African Republic, Chad, Congo,”-. 
&”Ivory Coast, Equatorial Guinea,Ethiopia,Gabon,Ghana, Guinea,”-! 
&”Guinea-Bissau,Kenya, Liberia, Madagascar, Mali, Mozambique, Nigeria,”-. 
&”Senegal, Seychelles, Sierra Leone, South Africa, Tanzania, Togo, Uganda,”-. 
&”Zaire, Zambia, Zimbabwe” after aircraft 

put return & ’’Asia & Australasia, Afghanistan, Australia, Bangladesh,”-. 
&”Brunei, Burma, Cambodia, China, India, Indonesia, Japan, North Korea,”-. 
&”South Korea, Laos, Malaysia, Mongolia, Nepal, Pakistan, Papua New Guinea,”-. 
&”Phillipines, Singapore, Sri Lanka, Taiwan, Thailand, Vietnam, New Zealand”-, 
after aircraft 

put return & ’’Carribean & Latin America, Argentina, The Bahamas, Belize,”-. 
&”Bolivia, Brazil, Chile, Colombia, Costa Rica, Cuba, Dominican Republic,”-. 
&”Ecuador,El Salvador, Guatemala, Guyana, Haiti, Honduras, Jamaica, Mexico,”-. 
&”Nicaragua, Panama, Paraguay ,Peru, Suriname, Uraguay, Venezuela”-, 
after aircraft 

get HPopupMenu(aircraft,0,The mouseV,The mouseH) 
if it <> 0 then 
put item 1 of it into row 
put item 2 of it into column 
if (row = 1) and (column =2) then 
go to card ”usn” 
end if 
end if 

end mouseDown 
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2. Surface Ships Button 
on mouseDown 
play ’’surface ships” 

put "United States,USN,USA,USCG” into ships 
put return & ’’Soviet Union” after ships 

put return & ”NATO,Belgium,Canada,Denmark,France,Germany, Greece,”-. 
&”Iceland, Italy, Netherlands, Norway, Portugal,Spain,Turkey,”-> 

&”United Kingdom” after ships 

put return & ’’Warsaw Pact,Bulgaria,Czechoslovakia,Hungary, Poland,”-. 
&”Romania” after ships 

put return & ’’Mideast & North Africa, Algeria, Djibouti, Egypt, Iran,”-. 
&”Iraq, Israel, Jordan, Kuwait, Lebanon, Libya, Mauritania, Morroco, Oman,”-. 
&”Qatar, Saudi Arabia, Somali Republic, Sudan, Syria, Tunisia,”-. 

&”United Arab Emirates, North Yemen,South Yemen”after ships 

put return & ”Sub-Saharan Africa, Angola, Benin, Cameroon, Cape Verde,”-. 
&”Ivory Coast,Ethiopia, Gabon, Ghana, Kenya,Liberia, Madagascar, Nigeria,”-, 
&”Senegal, Sierra Leone, South Africa, Tanzania” after ships 

put return & "Asia & Australasia, Australia,Bangladesh,Brunei, Burma,”-. 
&”Cambodia, China, Fiji, India, Indonesia,Japan, North Korea, South Korea,”-. 
&”Malaysia, Pakistan, Papua New Guinea, Phillipines, Singapore, Sri Lanka,”-. 
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&’Tai wan, Thailand, Vietnam, New Zealand” after ships 



put return & ’’Carribean & Latin America, Argentina, Bolivia, Brazil,”-! 
&”Chile, Colombia, Cuba, Ecuador, Mexico, Nicaragua, Paraguay, Peru, Uraguay,”-. 
&”Venezuela” after ships 

get HPopupMenu(ships,0,The mouse V, The mouseH) 
if it <> 0 then 
put item 1 of it into row 
put item 2 of it into column 
if (row = 1 ) and (column =2) then 
go to card ”usnl” 
end if 
end if 

end mouseDown 

3. Submarines Button 
on mouseDown 
play ’’submarines” 

put ’’United States” into submarines 

put return & ’’Soviet Union” after submarines 

put return & ’’NATO, Belgium, Canada, Denmark, France, Germany, Greece,”-. 
&”Iceland, Italy, Netherlands, Norway, Portugal, Spain, Turkey,”-. 

&”United Kingdom” after submarines 
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put return & ’’Warsaw Pact, Bulgaria, Poland, Romania” after submarines 

put return & ’’Mideast & North Africa, Algeria,Egypt,Israel,Libya,”-. 

&”Syria” after submarines 

put return & ’’Sub-Saharan Africa, South Africa” after submarines 

put return & ’’Asia & Australasia, Australia, China, Indiajndonesia,”-. 
&”Japan,North Korea, South Korea, Pakistan, Taiwan” after submarines 

put return & ’’Carribean & Latin America, Argentina, Brazil, Chile,”-. 
&”Colombia,Cuba, Ecuador, Peru, Venezuela” after submarines 

get HPopupMenu(submarines,0,The mouseV,The mouseH) 
if it <> 0 then 
put item 1 of it into row 
put item 2 of it into column 
if (row = 1) and (column =1) then 
go to card ’’subs” 
end if 
end if 

end mouseDown 

B. CODE FOR THE DEPARTMENT/SQUADRON/SHIP TYPE 
MENUS 
1. Aircraft 

on mouseDown 
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put ”FA- 1 8” into va 



get HPopupMenu(va,0,The mouseV,The mouseH) 

if it <> 0 then 
put item 1 of it into row 
put item 2 of it into column 
if (row = 1) and (column =1) then 
push card 

go to stack ”u.s. aircraft” 
end if 
end if 

end mouseDown 

2. Surface Ships 
on mouseDown 

put ”CG, Belknap, Leahy,Ticonderoga” into crudes 

put return & ”CGN,Bainbridge, California, Long Beach, Truxton,”-. 
&”Virginia” after crudes 

put return & ”DD,Spruance” after crudes 

put return & ”DDG, Adams, Arleigh Burke, Coontz, Kidd” after crudes 
put return & ”FF,Bronstein,Glover,Knox” after crudes 
put return & ”FFG,01iver Hazard Perry” after crudes 
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get HPopupMenu(crudes,0,The mouseV,The mouseH) 



if it <> 0 then 
put item 1 of it into row 
put item 2 of it into column 
if (row = 6) and (column =2) then 
push card 

go to stack ”u.s. surface ships” 
end if 
end if 

end mouseDown 
3. Submarines 
on mouseDown 
put ’’Ethan Allen” into ssn 

put return & ’’Glenard P. Lipscomb” after ssn 

put return & ”Los Angeles” after ssn 

put return & ’’Narwhal” after ssn 

put return & "Permit” after ssn 

put return & ’’Seawolf” after ssn 

put return & ’’Skipjack” after ssn 
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put return & ’’Sturgeon” after ssn 



get HPopupMenu(ssn,0,The mouse V, The mouseH) 

if it <> 0 then 
put item 1 of it into row 
put item 2 of it into column 
if (row = 3) and (column =1) then 
push card 

go to stack ”u.s. submarines” 
end if 
end if 

end mouseDown 

C. CODE FOR THE PLATFORM CARDS 
1. F/A-l 8 (Hornet) 
on mouseDown 

put ’’Guns, 20mm Machine Gun” into aaw 

put return & "Missiles, Sidewinder,Sparrow” after aaw 

get HPopupMenu(aaw,0,The mouseV,The mouseH) 

if it <> 0 then 
put item 1 of it into row 
put item 2 of it into column 
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if (row =1) and (column = 2) then 
show card field ”20mm” 
else if (row = 2) and (column = 2) then 
show card field "sidewinder” 
else show card field ”sparrow” 
end if 

end mouseDown 

2. Oliver Hazard Perry (FFG-7) 
on mouseDown 

put "Missiles, Standard Missile” into aaw 

put return & "Guns,76mm,20mm CIWS” after aaw 

get HPopupMenu(aaw,0,The mouse V, The mouseH) 

if it <> 0 then 
put item 1 of it into row 
put item 2 of it into column 
if (row = 1 ) and (column = 2) then 
show card field "standard missile” 
else if (row = 2) and (column = 2) then 
show card field ”76mm” 
else show card field ”20mm CIWS” 
end if 

end mouseDown 

3. Los Angeles (SSN 688) 
on mouseDown 
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put ’’Missiles, Harpoon, Tomahawk” into asuw 

put return & ”Torpedos,Mk-48” after asuw 

get HPopupMenu(asuw,0,The mouseV,The mouseH) 

if it <> 0 then 
put item 1 of it into row 
put item 2 of it into column 
if (row =1) and (column = 2) then 
show card field ’’harpoon” 
else if (row = 1) and (column = 3) then 
show card field ’’tomahawk” 
else show card field ”mk-48” 
end if 

end mouseDown 

D. SEARCH ALGORITHM CODE 
1. Search script 
on retuminField 

put empty into card field ’’Found Card List” 

set the lockMessages to true 

set the lockRecent to true 

set the lockScreen to true 

put card field ’’search criteria” into wordToFind 

put card field ’’stacks to search” into stacksList 

push this card 
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repeat with x = 1 to the number of lines in stacksList 
go stack (line x of stacksList) 
unmark all cards 

mark cards by finding wordToFind 
repeat with y = 1 to the number of marked cards 
put (the short name of marked card y) & 
the short name of this stack & return after foundCardList 
end repeat 
end repeat 

delete last char of foundCardList 
pop card 

put foundCardList into card field ’’Found Card List” 
set the lockMessages to false 
set the lockRecent to false 
set the lockScreen to false 
end retuminField 

2. Clickline 
on mouseDown 

get the value of the clickLine 
push card 

go card (item 1 of it) of stack (item 2 of it) 
end mouseDown 

3. Stacks to Search 

Card field ’’Stacks to Search” contains the following names: 
u.s. aircraft 



36 



u.s. surface ships 
u.s. submarines 
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APPENDIX B 



THREAT EVALUATOR USER’S MANUAL 
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A. INTRODUCTION 



The Threat Evaluator is an application that automates many of the functions 
that are required during the normal watchstanding routine of a Tactical Action 
Officer (TAO). Threat Evaluator can be implemented as an additional module to 
the Argos System or as a stand alone application. It is the most tailored tool to 
date that a TAO has available for continuous personal training as well as 
evaluation of platforms that may pose a possible threat to the safety of the ship. 

To start the Threat Evaluator application, double click on the icon shown in 
Figure 1. 




Threat Evaluator 

Figure 1 Threat Evaluator Icon 



B. MAIN MENU SYSTEM 

After startup, the user is taken to the main menu screen of the Threat 
Evaluator as shown in Figure 2. From this screen the user has many options 
available The horizontal dividing line in the center of the screen distinguishes 
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Figure 2 Main Menu Screen 



the training portion of the Threat Evaluator application from the tactical 
portions. The upper half of the main menu screen contains the aircraft, surface 
ships and submarines menus which make up the training portion of the 
application or proceed to specific tactical operations such as Search and Identify, 
TAO Status Board or Tactical Algorithms. Menus on the upper portion of the 
screen are accessed by clicking on the area desired, such as Aircraft, and holding 
the mouse button down (see Figure 3). This will then show a popup menu where 
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Figure 3 Popup Menus 

selection of a particular country within a geographic region can be made. In the 
popup menus for each of the aircraft, surface ships and submarines icons, 
countries are divided into geographic regions. After the selection of a country, 
the user is taken to another menu where selection of an agency, within the 
country selected, that has control of the original type platforms selected (i.e. 
aircraft) can be made. As shown in Figure 4, after the selection of the particular 
agency, i.e. “USN” under the Aircraft main menu icon, the screen changes to 
display the departments, or squadrons, within the agency. The user then has 
access to the individual aircraft type within the department or squadron 
designation. 
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Figure 4 Department/Agency Screen 



C. AIRCRAFT, SURFACE SHIPS AND SUBMARINES CARDS 

After a specific aircraft, surface ship or submarine is chosen the user is then 
shown the card with that specific platform. An example of an aircraft card is 
shown in Figure 5. 
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Figure 5 Aircraft Data Card 

On the card, features that will be of assistance to the user are divided into 
four warfare areas. These areas are anti-air warfare (AAW), anti-surface 
warfare (ASUW), anti-submarine warfare (ASW), and electronic warfare (EW). 
There are many other warfare areas, however, since this is a prototype 
application, only four were chosen to demonstrate the concept. Repetition of the 
equipment that appear under these menus is purposely done to show the 
possibilities of using a certain system across warfare areas. An example of this is 
a surface to air missile that may also be used in a surface to surface mode. After 
a system is selected from the menu of a warfare area, a window appears (Figure 
6) that contains specific data and characteristics that a TAO may require for 
tactical evaluation. To close the window, simply click on the window with the 
cursor. 
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Figure 6 Information Window 



D. SEARCH AND IDENTIFY FUNCTION 

One of the most useful functions that is available to a TAO in the Threat 
Evaluator application is the Search and Identify option. This option is vital for 
the quick identification of possible threats associated with a particular emitter or 
weapons systems. The screen for the Search and Identify screen is shown in 
Figure 7. 
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Figure 7 Search and Identify Screen 



The search function is designed to accept as input the name of a radar or 
weapon system that has been identified. With this information the search 
algorithm will search each platform card for a match to the system entered by 
the user. Upon a match, the names of platforms which have that emitter or 
weapon system will be displayed in a window for the TAO to view. If the TAO 
desires further information on a particular platform that has been identified in 
the list, he or she merely uses the mouse to click on the desired platform’s name 
and the information card of that platform will be displayed. The TAO can then 
evaluate in detail the capabilities of the platform by selecting the appropriate 
warfare area as described earlier in the Aircraft, Surface Ships and Submarines 
Card section. 
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E. TAO STATUS BOARD 



The TAO status board is accessed through the main menu screen and is an 
exceptional tool available to the TAO. It is ideal for easy access to all required 
perishable own ships’ information. This portion of the Threat Evaluator 
provides routinely needed data to the TAO and provides continuity in watch to 
watch turnovers. The TAO status board is comprised of two cards that display 
critical ships information. The combination of these two cards ensures that the 
TAO has available at his fingertips all essential data for fighting the ship. 

The first card of the TAO status board displays tactical weapons systems’ 
information. This card is shown in Figure 8. Weapons status and the condition 
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Figure 8 TAO Status Board Screen 
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of readiness that the ship is in are displayed at the top of the screen. Changes to 
these are accomplished by clicking the cursor on the desired button. The rest of 
the screen is divided into three main segments. 

The segment on the left of the screen contains ASW data and information on 
the specific ASW weapons systems of the ship. Information such as the search 
mode of the sonar, water conditions for the day and torpedo loading data are 
input by typing the information in the spaces provided or by clicking on the 
appropriate buttons. 

The segment on the right of the screen contains information on the gun 
systems aboard the ship. The information such as number of rounds and the 
status of the chaff can be changed by typing the information into the spaces 
available or by clicking on the desired buttons. 

The segment on the lower center of the screen shows the remaining missiles 
and their locations in the magazine. This information is required to provide the 
TAO a current missile magazine inventory update. The button shown in Figure 
9, will take the user to the second screen of the TAO status board. 




Figure 9 Combat Systems/Engineering Icon 

The second screen of the TAO status board is divided into two sections. The 
left section on the screen is the combat systems status and the section on the right 
of the screen is the engineering status. The material condition of these two areas 
can effect the combat readiness and therefore the survivability of a ship in 
combat. If there is any degradation in the equipment, then the TAO must be 



47 



aware of what is not working and what effect its’ failure has on the combat 
readiness of the ship. Information such as this is input by typing the information 
into the appropriately labelled spaces available or by clicking on the desired 
buttons. The Combat Systems and Engineering status screen is shown in Figure 
10 . 
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Figure 10 Combat Systems/Engineering Screen 



F. TACTICAL ALGORITHMS 

Tactical Algorithms are accessed through the main menu screen. This is a 
module that would greatly assist the TAO in weapons selection and employment. 
Tactical Algorithms would provide the user with a method of quickly calculating 
the probability of a kill against a particular target with a selected ship’s weapon. 
This would then aid the TAO in determining the optimum weapon mix and 
release point against the target. 
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G. EASY ACCESS BUTTONS 

Throughout the Threat Evaluator, the TAO has access to a number of 
buttons. These buttons provide access to certain modules and functions which 
include Battle Orders, Rules of Engagement, Night Orders, TAO Pass Down 
Log, INCSEA signals, Allied Tactical Publication signals, Find function, Help 
stack. Home stack access. Return, Print, and Return to Main Menu commands. 
These features are described in detail in the following sections. 

1. Battle Orders 

The Commanding Officer’s battle orders are contained in this section. 
Access to them is achieved by clicking on the icon shown in Figure 11. Within 
the screen is an icon that will give a time and date stamp if required. This icon is 
shown in Figure 12. 




Figure 11 Battle Orders Icon 




Figure 12 Time/Date Stamp Icon 
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2. Rules of Engagement (ROE) 

The Rules of Engagement are contained in this section. Access to them 
is achieved by clicking on the icon shown in Figure 13. A time and date stamp 
function is also avaiable on this screen. 




Figure 13 Rules of Engagement Icon 

3. Night Orders 

The Commanding Officer’s night orders are contained in this section. 
Access to them is achieved by clicking on the icon shown in Figure 14. A time 
and date stamp function is also avaiable on this screen. 




Figure 14 Night Orders Icon 



4. TAO Pass Down Log (PDL) 

The TAO Pass Down Log is contained in this section. Access to it is 
achieved by clicking on the icon shown in Figure 15. A time and date stamp 
function is also avaiable on this screen. 
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Figure 15 TAO Pass Down Log Icon 



5. INCSEA 

The INCSEA signals will be accessed through the icon shown in Figure 
16. The module w'ould contain all the signals from the agreement. These signals 
would be displayed either in a list or a specific signal could be decoded as 
desired. The signal would be input by the TAO, resulting in the decoded 
meaning being displayed on the screen. This would give the TAO quick access to 
required information. As envisioned, signals could also be encoded using this 
system tool. 




Figure 16 INCSEA Incon 

6. Allied Tactical Publication (ATP) 

The ATP- 1(C) signals will be accessed through the icon shown in 
Figure 17. The module v/ould contain all the signals from the ATP- 1(C) as well 
as the information describing general maneuvers.. These signals would be 
displayed either in a list or a specific signal could be decoded as desired. The 
signal would be input by the TAO, resulting in the decoded meaning being 
displayed on the screen. This would give the TAO quick access to required 
information. As envisioned, signals could also be encoded using this system tool. 
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A completely integrated, fully implemented module would also provide the user 
with a complete maneuvering board solution, i.e. course and speed to station. 




Figure 17 ATP Icon 



7. Find 

The Find function will be accessed through the icon shown in Figure 
18. The application will query the TAO as to what platform he wishes to view. 
The TAO then inputs a name, i.e. Los Angeles, and the Find function will take 
the user to that card. 




Figure 18 Find Icon 



8. Help 

The Help stack will be accessed through the icon shown in Figure 19. 
This contains useful information on operation of the Threat Evaluator. If a user 
does not remember the function of an specific icon, then the help stack would 
assist him or her in determining its’ use. 



52 




Figure 19 Help Stack Icon 



9. Home Stack 

The Home stack will be accessed through the icon shown in Figure 20. 
This takes the user to the home card of the HyperCard environment. 




Figure 20 Home Card Icon 



10. Return 

The Return command will be accessed through the icon shown in Figure 
21. This button returns the user to the previous screen. 

Figure 21 The Return Icon 



11. Print 

The Print command will be accessed through the icon shown in Figure 
22. This allows the user to print items if required. 
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Figure 22 The Print Icon 



12. Return to Main Menu Button 

The Return to Main Menu button will be accessed through the icon 
shown in Figure 23. This allows the user to return to the main menu screen fron 
any location in the Threat Evaluator. This gives easy access to the main menu by 
a single click on the mouse. 




Figure 23 The Return to Main Menu Button 
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